

Serial Tunnelling: 

Spoofing Your SNA Network 

SNA networks become increasingly intertwined with other network types as users’ 
multivendor networks are internetworked. This article discusses products and 
strategies from vendors of multiprotocol routers which are designed to operate in 
SNA networks—both traditional subarea and APPN. 

Most vendors of multiprotocol routers have expressed their intention to accommodate 
SNA in their internetworking plans by providing a multi-stage roll-out of IBM 
connectivity products (see SNA Perspective, April 1991). The eventual goal of these 
companies seems to be to provide some level of native SNA routing support—APPN 
and subarea node types. 

(continued on page 2) 

IBM’s Marathon Runner: 

The Communication Controller 

SNA Perspective could make a loud splash by joining the chorus predicting the 
demise of the communication controller. But we won’t because we don’t believe it. 
The IBM 3745 communication controller certainly faces challenges from a wide 
range of products and protocols inside and outside of the company, including IBM’s 
own 3172 Interconnect Controller. We do not believe it will be the omnibus 
communications node, but then no single product from any vendor will serve all 
needs. The communication controller is being adapted to continue to serve many 
data communications needs of SNA users, and the many 1991 announcements have 
given a clearer picture of its future. 

This article reviews the evolving role of the communication controller, from 
supporting BSC, SDLC, switched lines, X.25 and LANs to multiprotocol routing and 
emerging WAN technologies such as frame relay and SMDS. We examine some of 
the challenges from multiprotocol internetworking products and discuss some 
tradeoffs in replacing communication controllers as internetworking nodes. TCP/IP 
and OSI support as well as APPN directions for the 3745 are reviewed. We will look 
at several types of 3745 connectivity and assess their role and importance in today’s 
SNA networks. 
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Multiprotocol Router 
Accommodation of SNA 

Cisco Systems of Menlo Park, California unveiled a 
five-phase strategy for IBM connectivity in January. 
Proteon, Inc. of Westborough, Massachusetts 
announced in June a three-stage SNA strategy to 
accomplish SNA routing. Vitalink Communications 
of Fremont, California announced initial SNA 
products in September and detailed its strategy at 
that time for routing of SNA 

Due to the extreme coritplexity of SNA routing and 
the unclear future path of SNA networking, most of 
these vendors are either planning or providing 
simple, short-term solutions to accommodate SNA. 
Multiprotocol router companies that have either 
announced or released products that support SNA 
traffic include Cisco Systems, CrossComm, Proteon, 
Vitalink, and Wellfleet. 

All of these simpler short-term solutions address 
SNA at the data link level. Strictly speaking, SNA 
doesn’t even specify the architecture of the data link 
layer—it merely assumes that a reliable, connection- 
oriented data transport mechanism exists beneath the' 
path control layer. This decoupling of SNA from 
specific data links has resulted in the ability to 
transport SNA across a variety of media—serial 
lines using SDLC, token-passing networks using 
token ring, and contention networks using Ethernet. 

It is this characteristic that is being exploited by 
multiprotocol vendors. 

Tunnelling of 
SNA Serial Traffic 

The method many current vendors use to support 
SNA devices is a safe and relatively easy technique 
known as serial tunnelling, also commonly referred 
to as synchronous passthrough. Since the data link 
protocol that IBM uses on serial links is 
Synchronous Data Link Control (SDLC), this 
method is sometimes called SDLC tunnelling. 


(The term tunnelling merely means that a complex 
network with all its own formats and protocols is 
treated as a simple channel for the delivery of data.) 

Using serial tunnelling, any serial link that is used to 
connect two IBM systems together can be replaced 
by a pair of routers and their interconnection 
network. This method will typically be used to 
connect 37x5 communication controllers with 
remote, SDLC-attached 3x74 establishment 
controllers. But it can also be used for connecting 
intermediate 37x5 communication controller subarea 
nodes. These two placement points for SDLC links 
are shown in Figure 1. 

The flexibility of serial tunnelling extends beyond 
the SNA subarea network shown in Figure 1. 
Because the serial tunnel is insensitive to the 
characteristics of the source and destination devices, 
serial tunnelling can also be used to connect the , 
nodes of an Advanced Peer-to-Peer Networking 
(APPN) network. v 

Benefits of Serial Tunnelling 

At first, it appears that this technique merely adds 
communication components to the network and 
therefore increases its complexity rather than 
simplifying it After all, why would a customer 
want to replace an inexpensive pair of modems and a 
simple serial line with a pair of moderately expen¬ 
sive routers and their interconnection network? The 
answer lies in an examination of corporate networks 
after a decade of LAN integration. 



Figure 1 
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Many companies today connect their geographically 
dispersed LANs with multiprotocol bridges and 
routers while maintaining a separate SNA backbone 
network. This requires two distinct wide area 
connections—one for each network. Often, the 
interconnected LANs are in close proximity to the 
SNA nodes. In this case, the two separate remote 
links can be collapsed into a single wide area 
network connection by using a multiprotocol router 
that supports both LAN bridging/routing and SNA 
serial tunnelling. This consolidation of wide area 
links is shown in Figure 2. The situation depicted in 
that diagram is today’s prime motivation for 
multiprotocol routers to provide some kind of 
support for SNA traffic. 

Serial Tunnelling Mechanics 
In the case where serial traffic is tunnelled through 
an IP network, the frames are encapsulated within IP 
packets. However, as mentioned above, SNA 
assumes that the underlying data link is connection- 
oriented and can deliver SNA data in a reliable 
manner. Since IP is an unreliable connectionless 


Motivation for Serial Tunnelling 



Figure 2 


network protocol (e.g., it may discard packets during 
peak load conditions), using IP by itself will not 
suffice. By convention, transport protocols that use 
the underlying IP networking services provide the 
end-to-end reliability. 

The most common transport level protocol used with 
DP networks is the Transmission Control Protocol 
(TCP). TCP is a reliable, stream-oriented transport 
service that maintains a virtual circuit across an IP 
network and guarantees an ordered delivery of TCP 
packets. As a result, SDLC transport across an IP 
network usually means that SDLC frames are 
actually carried inside TCP packets, which, in turn* 
are inside IP packets. This successive layering is 
shown in Figure 3. - 

The heart of the serial tunnelling support on 
multiprotocol routers is the operation of the 
specialized ports that act as the interface between the 
SNA devices and the internetwork. This pair of 
ports—one at each end of the serial tunnel—provide 
two major operations: 


SDLC Encapsulation Inside IP 
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• Locally, they provide an interface into the tunnel 
for the SNA devices 

• Remotely, they communicate with each other 
across the network in order to make the tunnel 
transparent to the devices at either end 

The first operation is rather simple—the interface at 
the router must be able to both send and receive 
SDLC control and information frames. As noted 
above, these frames are then encapsulated in TCP/IP 
packets and sent across the network. 

The second operation is where the multiprotocol 
vendors provide significant added value. How the 
tunnelled traffic is mapped onto the underlying inter¬ 
networking services varies with each vendor. 
Mapping a virtual circuit-oriented architecture like 
SNA onto an internetworking architecture presents 
some interesting challenges and, depending upon 
the implementation, may or may not affect the SNA 
end user. 


Tunnelling’s Impact On the 
SNA End User 

The IP networie “cloud” in Figure 3 could be, in 
reality, a rather complex set of diverse paths across 
different types of media. This, together with the fact 
that the IP network architecture is totally connec¬ 
tionless and datagram-oriented, means that there is a 
completely nondeterministic delivery system 
beneath SNA. 

SNA was designed with the assumption that a 
reliable, connection-oriented data link mechanism 
existed beneath the upper layers of the protocol, and 
that the SNA data link control layer provided tightly 
bounded, deterministic delivery of packets. This 
inherent assumption in the design of SNA is violated 
with the tunnelling of SDLC packets across IP 
networks. The effect of this mapping of services 
from one network architecture to another on the end 
user results, at best, in variable response time and, at 
worst, in session outage. * 

Variable response time is the curse of system 
administrators—being perhaps even more frustrating 


than consistently poor response time. With a virtual 
circuit architecture like SNA, placing higher perfor¬ 
mance media and components into an overloaded 
communications path between the end user and the 
mainframe will always result in quantifiably lower 
response time. 

Obviously, adding higher performance media in an 
IP network improves the overall performance of that 
network. But, since the architecture permits the 
routing elements to discard packets when a node gets 
overloaded, there is effectively no way to guarantee 
elimination of the nondeterministic behavior of IP 
networks. In a large BP network with a potentially 
large end-to-end delay, this becomes a critical 
problem. - 

The primary SDLC link station (usually at the host 
end of the SDLC link) maintains an idle timer to 
ensure that the secondary SDLC link station (usually 
at the establishment controller end) responds to polls 
within an adequate amount of time. If the secondary 
link station does not respond quickly enough, the 
host assumes that the link has failed and initiates 
outage procedures for SNA sessions that were active 
on that SDLC link. Since there is no way for an IP 
network to guarantee the delivery of SDLC 
information frames before the idle timer expires, 
session loss across serial tunnels is a real possibility. 
As the size of the underlying IP network increases 
and/or the amount of traffic carried by the IP 
network increases, the SDLC idle timeout problem 
becomes even more acute. 

There are ways around this problem. The NCP gen 
is quite flexible in the specification of values for the 
SDLC idle timeout. These timers are adjustable and 
can be increased to some maximum value that will 
never happen. 

Serial Tunnelling 
Optimizations 

Some of these misgivings about serial tunnelling 
across IP networks have been addressed by the 
vendors of multiprotocol routers. Perhaps the 
greatest win is a feature known as poll spoofing. 
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sometimes called “remote polling” or “proxy 
polling.” 

Poll Spoofing 

As mentioned above, there is an idle timer for each 
SDLC link in order to determine if the link 
connection has dropped. For a healthy SDLC link 
that is not actively transferring data, there are 
continuous polls from the primary SDLC link station 
and poll acknowledgments from the secondary. 
(These are sometimes referred to as “session keep¬ 
alive frames.”) SDLC polls and poll acknowledg¬ 
ments are, in reality, two-byte SDLC Receiver 
Ready (RR) control frames. If these two-byte SDLC 
frames are encapsulated inside a TCP/IP packet with 
(at least) a 20-byte TCP header and a 20-byte IP 
header, this means that continuous 42-byte IP 
packets would traverse the IP network even when 
the SNA end stations do not have any data to 
transmit As SNA traffic on the TCP/IP network 
increases, this could impact network performance. 

The serial tunnelling products from some multi¬ 
protocol router vendors provide poll spoofing. As 
an example, Cisco’s poll spoofing feature is called 
proxy polling. It terminates the SDLC polls at the 
router port and therefore takes the majority of the 
nonproductive SDLC traffic off the network. The 
Cisco router connected to the 3745 communication 
controller issues poll acknowledgments to the SDLC 
polls from the communication controller while the 
router that is connected to the establishment 
controller issues polls to the 3x74. Therefore, the 
SDLC session is kept alive at either end of the 
connection even though there is no traffic traversing 
the internetwork. 

When either side receives actual SDLC data instead 
of a poll or poll acknowledgment, the routers then 
perform the encapsulation and route the packet 
through the network. The data is then presented to 
the SNA end device as if the data just became 
available from the partner device. While this 
technique greatly reduces the amount of 
internetwork traffic, it does increase the buffering 
requirements of the routers and makes for a more* 
complicated software design. The mechanism of 
poll spoofing is shown in Figure 4. 


There is a much larger benefit to poll spoofing than 
reducing the overhead traffic load in the 
internetwork. The host gen is no longer sensitive to 
the internetwork delays that could occur in the 
tunnel. Since the SDLC connection is kept alive at 
the directly attached router, the SNA end devices 
never see these internetwork delays. 

Notice also in Figure 4 that poll spoofing requires 
two variants of the SDLC drivers in the routers. 
There is a secondary link station at the 3745 end of 
the tunnel and a primary link station at the 3x74 end 
of the tunnel. In traditional hierarchical SNA 
networking, this means that the upstream router is 
configured as a secondary SDLC link station while 
the downstream router is configured as a primary 
SDLC link station. This relationship always holds 
since the communication controller is always the 
primary link station. 

Discovering Link Station Role 

However, this rule is broken in APPN networks and 
will also be broken in SNA subarea networks once 
communication controllers acquire more peer-to- 
peer functionality than they have today. SNA peer- 
oriented communication requires the SDLC link 
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stations to negotiate their respective primary and 
secondary roles at link start-up time. This means 
that the router cannot know a priori which link 
station role it must assume in the poll spoofing 
dialogue with the real SNA device. Some mech¬ 
anism must be implemented that lets the router 
determine which link station role it must assume. 
Cisco calls this process link station role discovery 
and states that it assists in flexible SDLC tunnelling. 

Priority Assignment 

A feature called priority assignment, to be included 
in Proteon’s SDLC tunnelling product in 1992, will 
reduce the effect on the SNA end user of the non- 
determinism of themtervening IP network. Its 
SDLC relay attempts to provide the same predictable 
response time by assigning a higher priority to SDLC 
traffic through the IP network. The feature that 
Cisco offers in its serial tunnelling product directed 
at this same goal is load balancing. If the SDLC 
traffic is being transported across an IP network, the 
routing protocol on the IP network may be able to do 
load balancing. This algorithm provides a method to 
select alternate paths through an IP network in order 
to obtain a more balanced traffic flow. 

Another feature to reduce or eliminate the effects of 
an IP network is offered by some vendors with their 
serial tunnelling products. If the nondeterministic 
properties of an IP network are not acceptable to a 


particular SNA environment, then an alternate 
transport mechanism is provided. These serial 
tunnelling products permit the encapsulation of 
SDLC traffic inside HDLC information frames for 
transport across a point-to-point serial network. The 
encapsulation overhead can be very small—even 
four bytes—and the nondeterministic properties are 
reduced or eliminated. This configuration would 
allow SNA sites to upgrade their existing SNA wide 
area network services to use multiprotocol routers 
without the potential of adversely affecting the 
response time characteristics of the existing network. 

Miscellaneous Serial 
Tunnelling Features 

Vendors have included other miscellaneous features 
in their serial tunnelling products in order to add value 
to them. Some of the more interesting ones are: 

Link Redundancy 

Many bridge/routers provide a mechanism to con¬ 
figure multiple links between two routers that 
implement serial tunnelling. While only one link is 
used to transfer data between the routers, the routers 
can automatically switch to a backup path should the 
active link be lost. 


Serial Tunnelling Feature by Vendor 


Vendor/ 

Feature 

Cisco Systems 
Serial Tunnel (STUN) 

Wellfleet 

Sync Pass Thru 

CrossComm 

SDLC Pass Through 

Proteon 

SDLC Relay 

Encapsulation Technique 

IP or HDLC 

HDLC 

LLC Type 2 

IP 

Poll Spoofing 

Yes 

No 

No 

No 

Redundant links 

Yes 

No 

No 

No 

Serial products 

SDLC, HDLC, 
any ISO 3309-compliant 

SDLC, HDLC 

SDLC, HDLC 

SDLC 

Arbitrary media 

Yes 

No 

No 

Yes 

Load sharing 

Yes 

* No 

No 

Yes 

Priority assignment 

Yes 

No 

No 

Yes 







Table 1 
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Support for non-SDLC Serial Traffic 
Cisco, CrossComm, and Wellfleet all offer the serial 
tunnelling service to HDLC connections (for X.25 
traffic) as well as to SDLC. Cisco provides a 
mechanism to define any ISO 3309-compliant link 
level protocol for tunnelling. 

SDLC Link Station Address Transparency 

Vendors try to make their serial tunnelling protocols 
insensitive to the actual SDLC station addresses. It 
is therefore possible to tunnel two different SDLC 
streams from devices with the same SDLC link 
station address through the network using a single 
pair of routers. 

Table 1 summarizes the serial tunnelling offerings 
from the multiprotocol vendors who have either 
released or announced products. This table identifies 
various serial tunnelling features by vendor. 


SDLC Bridging 

An alternate to serial tunnelling, SDLC bridging is 
also a means of integrating SDLC devices into LAN- 
based internetworks. Unlike tunnelling, which uses 
SDLC on both host and device sides, SDLC bridges 
convert SNA traffic from SDLC to other data link • 
layers such as the LLC format. This allows SDLC 
devices to communicate directly with a LAN- 
attached SNA communication controller, rather than 
through an SDLC communication controller 
interface. 

Vitalink is the first internetworking vendor to 
provide SDLC bridging, which it announced in 
September. Other companies, including Cisco, 
Netlink, Sync Research, and Wellfleet have also 
announced this capability, and SNA Perspective 
expects that other internetworking vendors will add 
it too. 


Summary 

This article has discussed in detail the technology of 
SDLC tunnelling by multiprotocol vendors. SDLC 
tunnelling represents the first stage of products from 
the multiprotocol vendors to address the needs of 
SNA interoperability but will definitely not be the 
last. However, due to the complexity of routing 
SNA in a native manner, these serial tunnelling 
products will be around for several years. 

While these products represent a rather simple form 
of SNA interoperability, they are sensitive to the 
underlying transport network characteristics. Some 
of those characteristics manifest themselves to SNA 
end users in ways they might not be accustomed to, 
such as variable response time and session loss. 

Advantages of Serial tunnelling are: 

• Customers are able to take advantage of 
advances in multiprotocol router technology 
while maintaining their SNA networks 

• The existence of a serial tunnel under SNA does 
not significantly affect most host gens 

• Serial tunnelling is unaffected by changes in SNA 
Disadvantages of serial tunnelling are: 

• Without poll spoofing, SNA sessions are sen¬ 
sitive to data link timeouts resulting in loss of 
session 

• If the serial tunnel is across a network with non- 
deterministic delivery properties, then the SNA 
end users are subject to variable response times 

Some of the more advanced features vendors may 
offer with their serial tunnelling products are: 

• Poll spoofing 

• Priority transmission through IP networks 

• Transport across any serial medium ■ 
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NCR 56xx Series Communication Processors 


NCR’s SNA Business Unit (SBU) (formerly NCR 
Comten) has five different models of commu¬ 
nication processors, together with software 
products for them. NCR has been in the SNA 
communications business for 20 years and has 
more than 3,500 communication processors 
installed. 

The company’s communication processors use its 
own NCR Comten Advanced Communications 
Function/Network Control Program (ACF/NCP) 
instead of (although it’s compatible with) IBM’s 
Network Control Program (NCP). Rather than 
merely follow in IBM’s footsteps, this has allowed 
NCR to incorporate T such innovations in its 
communication processor as Ethernet, TCP/IP f 
and 1,024-line connectivity. 

NCR has been highly focused on integrating open 
systems with SNA on a single communication 
processor in support of the trend away from 
vendor-proprietary architectures and toward open 
communication. The most recent result has been 
a second release of its TCP/IP protocol stack. 

OSI protocols are also under development, to be 
released when there is sufficient demand. 

New Announcements 

In October, NCR’s SBU announced several new 
products—5630 communication processor family, 
Multiple Communications Adapter Module 
(MCAM), and NCR Comten TCP/IP Release 2. 

The new 5630 family is discussed below. The 
MCAM supports LAN and WAN connectivity to the 
communication processor. It is an intelligent 
subsystem, I/O controller platform based on the 
486 microprocessor, microchannel architecture, 
and SCSI technology. TCP/IP Release 2 will 
support enhanced host applications and network- 
based functions. 

NCR Comten 56xx Models 
NCR’s Comten communication processors range 
from the new, low-end processor, the 5630, up to 
the high-end 5675-B, with three models in between. 

The 5630, designed for the same market segment 
as the IBM 3745 1x0 series, has performance 
advantages over IBM. The 5630 can support up 
to 32 full-duplex lines, and direct connection otup 
to sixteen 16/4 token ring or Ethernet LANs. The 
customer can also choose up to two channels, two 


T1 interfaces, or one channel and one T1 
interface. The 5630 prices start at $39,000. 

The NCR Comten 5675-B supports up to sixteen 
channels, up to 1,024 full-duplex lines, up to 24 
T1/E1 lines, and direct connection of up to 6416/4 
token ring or 48 Ethernet LANs. 

One unique advantage of NCR Comten 
communication processors is that the CPUs for 
the low-end and intermediate processor models 
each offer three levels of CPU performance. This 
means that the LAN throughput on each of these 
NCR Comten models can be increased by 
swapping out the CPU on an installed commu¬ 
nication processor. Since CPU performance can 
create a bottleneck when processing data from 
LANs, if they are being used at a high percentage 
of their considerable bandwidth, a customer can 
scale up an existing 56xx processor to the next 
higher processor. For example, a processor with 
a level 1 CPU can be upgraded to level 2 (the 
base CPU for the 5665) performance or to level 3, 
which is the CPU used in the high end 5675-B 
model. With IBM, to obtain a communication 
processor to handle a larger amount of LAN traffic, 
one would have to select from its high-end 410 or 
new 310 or 610 models. With the NCR Comten 
processors, the user does not need to buy a 
greater amount of connectivity connectivity just to 
support increased LAN traffic. 

TCP/IP and X.25 

NCR’s TCP/IP enables communications between 
IBM mainframes and systems from other vendors. 
It also provides peer-to-peer communications for 
applications, file transfers, and electronic mail. 
Further, it offers a TCP/IP LAN gateway to WANs. 
NCR provides a broad range of host and terminal 
X.25 packet assemblers/disassemblers (PADs). 

Multi-Vendor Networking Facility (MVNF) 
Designed to enhance the function of 3270 
terminals, MVNF provides end users with access 
to multiple 3270 host applications concurrently. 
The applications may reside in a wide variety of 
3270 host environments, including SNA, pre-SNA, 
non-SNA (multivendor), and X.25. 

For more information, contact: NCR Network 
Products Group, 2700 Snelling Avenue North, 

St. Paul, MN 55113, (612)638-7391. ■ 
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Amdahl 4745 Series Communication Processor 


Amdahl has been in the IBM-compatible commu¬ 
nications controller business for eleven years and 
has an installed base of over 1,200. Amdahl’s first 
communication processor (formally called front- 
end processor) was the 4705, then the 4725 and, 
for the past few years, the 4745. 

All Amdahl communication processor are IBM 
Network Control Program (NCP)-compatible, 
meaning they can run IBM software, while the 
NCR Comten products only support NCR 
Comten’s NCP emulation software. 

The 4745 is plug-compatible with IBM’s 3745, 
except for varying connectivity and hardware 
features supported. Plug-compatible means that 
an IBM 3745 can be replaced by an Amdahl 4745 
without making any changes to the IBM software, 
including the NCP or the physical network that 
connects to the communication processor. This 
allows for an easy transition from an IBM to an 
Amdahl product. Amdahl prices its products for a 
15 percent cost/performance advantage over IBM. 

The 4745 supports: 

• Both NCP Versions 4 and 5 (the IBM 3745 
does not support NCP Version 4, which runs 
on the 3725) which eases migration from 
3725- to 3745-type architecture. 

• Token ring LANs (4 Mbps currently, has 
committed to supply 16 Mbps). 

• 8 Mbyte memory capacity. 

• Automatic backup/recovery (Auto ISA) to 
enable one 4745 to assume the role of 
another 4745 in the event of a system failure. 


• Interfacing with the IBM 37x5 communication 
controller products 

On September 30,1991, Amdahl began general 
delivery of three new features: 

• A high-speed scanner that supports U.S. and 
European T1 data connections. 

• A high-performance feature that improves 
CCU and channel adapter performance. 
Performance was increased through the use 
of static RAM for the main storage unit, and 
new LSI technology and bus and tag handling 
on the channel adapter. Throughput is in¬ 
creased between 30 and 80 percent depen¬ 
ding on the networking environment. 

• The expanded channel connectivity feature 
allows connectivity to additional hosts, up to 
four on the Model 110 and eight on the 210. 

The 4745 is available in models 110 and 210. The 
4745-110 supports up to four channels, up to 64 
lines, one token ring adapter (TRA) with two 
4Mbps token ring LAN connections, and up to two 
high-speed scanners with two active and two 
backup T1 lines. The 4745-110 can be upgraded 
to the larger 210 model. The 4745-210 supports 
up to eight channels, up to 256 lines, up to two 
TRAs with four 4Mbps token ring LAN 
connections, and up to four high-speed scanners 
with four active and four backup T1 lines. Amdahl 
expects to support NCP Version 6 soon after it is 
available. 

For further information, contact: Amdahl 
Corporation, 1250 East Arques Avenue, 
Sunnyvale, CA 94088-3470, (408) 746-6000 ■ 


U.S. Installed Base 
September 1991 

IBM 15,081 

NCR 1,389 

Amdahl 424 

Others* 3,397 

Total U.S. 20,291 


Communication Controller Installed Base 

Computer Intelligence of La Jolla, California, estimates that about twenty 
thousand IBM and IBM-compatible communication controllers are installed in 
the United States. These include some devices that are not, strictly 
speaking, IBM-compatible communication controllers, but serve a similar 
front-end processor function. These also include some older hard-wired 
devices and many before the advent of NCP. 


*Others include CCI, IDEA 
Courier, Lemcom, Nixdorf, 
AT&T Paradyne, Commex, 
and Memorex Telex. 

Source: Computer Intelligence 


SNA Perspective estimates that the U.S. population of these devices 
represents about half of the worldwide installed base, which yields a 
worldwide base of 40,000. The majority of NCR and Amdahl communication 
controllers are outside the U.S. 
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(continued from page I) 


Nomenclature 

In this article, we will refer to the category of 
products represented by the IBM 3745 as 
communication controllers, which includes the older 
IBM 3705,3720, and 3725 as well. When we talk 
about future developments, however, we mean the 
IBM 3745 and the oft-rumored 3765. IBM used to 
call this class of product front-end processors (FEPs) 
before their functionality was enhanced to support 
generalized routing. The companies that make 
compatible products, Amdahl and NOR Comten, 
refer to them as communication processors. 


Traditional Data Circuits 

Two of the primary functions of a communication 
controller, as shown in Figure 5, are 

• Concentration: “concentrate” lower speed data 
lines to high-speed data lines 

• Connectivity: connect a large number and 
variety of data circuit types 

If the need for data circuit connectivity disappears 
because of LANs, will the need for communication 
controllers also disappear? We don’t think so. 



From the Demise of Multipoint... 

Because of corporate acceptance of token ring 
LANs, the traditional nonswitched (leased line) 
multipoint SDLC data circuits are declining rapidly. 
Switched, nonswitched, and token ring interfaces are 
shown in Figure 6. Locations supported by multi¬ 
point SDLC data circuits are excellent candidates for 
conversation to token ring or even Ethernet. 

Although SNA is not supported natively on 
Ethernet, a variety of gateways are available to 
provide SNA connectivity. If an existing SDLC 
establishment controller cannot accept a token ring 
adapter, products are now available that connect the 
controller to a token ring and enable the SDLC con¬ 
troller to access the host via token ring (see article in 
this issue on serial tunnelling, with SDLC Bridging 
on page 7). 

This reduction in data circuits does reduce the 
requirement for data circuit connectivity to 
communication controllers. 


Data Circuit Types 



Switched 


DSE = Data Switching Equipment 
DCE = Data Communications Equipment 


Figure 5 Figure 6 
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...and Continuance of Point-to-point... 

What will continue to exist, although it is unclear to 
what extent, is nonswitched point-to-point SDLC. 
The need for this is found in locations with a single 
establishment controller or workstation beyond the 
reach of a LAN multistation access unit (MAU). 
Some SNA gateways are also designed specifically 
to allow users on a LAN to communicate with an 
SNA host using either SDLC or token ring. In some 
cases, particularly if the LAN is Ethernet, point-to- 
point SDLC is the better choice. (We emphasize 
point-to-point here because if the connectivity needs 
require multidrop lines, as described above, a token 
ring would usually be more advantageous, even if it 
were to exist in parallel with the Ethernet LAN.) 

SDLC would be the more cost-effective choice: an 
SDLC card versus an MAU with a bridge or router. 
More importantly, network management is eased 
with the SDLC solution. Numbers of small SDLC 
segments are currently more effectively managed 
than multiple multiprotocol internetworked seg¬ 
ments. Further, using SDLC, problems can be 
managed and corrected using either Net View or 
VTAM. Currently, only a rudimentary central 
management facility exists for token ring LANs 
using NetBIOS. (For more details on LAN 
management see ‘Taming the Wild LAN: Systems 
Management,” SNA Perspective, February 1991.) 

Several companies offer multiprotocol routers that 
can transmit SDLC, as described in the companion 
article in this issue. This functionality enables a 
remote SDLC controller to be connected to a router 
at the remote site while the router at the local site is 
connected to a communication controller. This 
displaces the leased line previously used between the 
remote SDLC device and the communication 
controller by using the TCP/EP backbone. Only 
point-to-point SDLC is currently supported on these 
products. Several vendors also plan to improve 
SDLC support by incorporating a serial/token ring 
gateway—converting the SDLC traffic into LLC 
frames and passing it to the host using token ring. 
Rather than being limited to requiring a commu¬ 
nication controller to access the host from the LAN, 
they allow the use of any token ring interface to the 
host, including a 3172. An apparently logical, albeit 
large, next step would be for a multiprotocol router 


to emulate a local 3174 and communicate directly 
with VTAM via an IBM channel. But channel tech¬ 
nology doesn’t come easily and SNA Perspective 
expects that these router vendors would develop 
such capability jointly with companies with existing 
channel experience, such as Network Systems 
Corporation and McDATA. 

...to the Brighter Future of Switched 

Not only will switched SDLC continue to exist, but 
it, X.25, and dial-up asynchronous will grow to 
support small offices that do not require a leased 
line—single proprietorships and the emerging tele¬ 
commuter segment. The total number of American 
working at home either full- or part-time increased 
22 percent to 33 million in 1990. 

Thanks to developments in modem technology and 
improvements in phone line quality, (he days of slow 
response times and link dropping are over. Now 
with high-speed dialup modems, users can commu¬ 
nicate at data rates up to 38.4 kbps with confidence 
that the link will remain up because of sophisticated 
error correction. In addition to public data networks 
(PDNs) or value-added networks (VANs) based on 
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X.25, an SNA PDN, the Information Network, is 
offered by IBM and is available for networking SNA 
in native mode over a large geographical area. 

Figure 7 (page 11) shows how different routing 
networks, including SNA, can exist within a network 
“cloud,” regardless of the protocols being routed 
within the cloud. These networks can support a 
variety of protocols externally, though only those for 
which they have the capability to map into or 
envelop in the routing protocols that are used inside 
the cloud. For example, IBM’s communication 
controllers can now transport OSI (now) and TCP/IP 
(September 1992) traffic across an SNA backbone. 

Remote communication controllers can reduce the 
cost of remote dial-iriT'Tor example, a user may 
install a remote communication controller in a 
region with sufficient dial-in traffic from several 
locations in that region but which is located a 
significant distance from the data center. Then, 
using a leased line or WAN from the remote commu¬ 
nication controllers back to the data center, dial-up 
or WAN charges of the individual users can be 
substantially reduced. 

BSC Today 

Binary synchronous communications (BSC or 
bisync) is an outdated technology, superseded when 
SNA was introduced in 1974. We might expect it 
would have disappeared, but a surprisingly large 
amount of IBM-related data communications traffic 
is still BSC. Our discussions with users indicate that 
an average of 20 percent of all mainframe commu¬ 
nication lines today are BSC. This is backed by 
findings from Computer Intelligence of La Jolla, 
California, on the penetration of SNA in the United 
States. A 1990 report showed that VTAM was used 
at only 73 percent of all IBM and plug-compatible 
mainframe sites and also reported that nearly 70 
percent of sites still use BSC. The presence of BSC 
is only slightly lower in Fortune 1000 companies. 
However, this report covers only the United States; 
the presence of BSC is significantly lower outside 
the United States, since most of these mainframe 
networks postdate the 1974 introduction of SNA. 

In most cases, the BSC equipment or BSC emulators 
were chosen, remain, and are sometimes still chosen 
today purely for cost reasons, usually in spite of the 


data center’s recommendation of SNA technology. 
Communication controllers support BSC, but few 
vendors with multiprotocol products adding SNA 
support plan to support BSC. BSC equipment or the 
BSC emulation package would need to be replaced 
should the communication controller supporting 
them be replaced by a multiprotocol network. 
Replacing BSC with SDLC, or especially with token 
ring products with an associated LAN, would be 
very undesirable to these users from a cost standpoint 


Other Circuit Types 

X.25 and Frame Relay 

IBM has long provided extensive X.25 support on its 
communication controllers. In Europe, due to the 
proliferation of X.25 by the telephone companies, 
X.25 is extensively used and is expected to continue 
to grow significantly in the future. Demand for X.25 
connectivity in communication controllers for 
Europe will remain strong. 

In the United States, the use of X.25 has been 
growing, though it has not become as widespread as 
it is in Europe. However, this growth is expected to 
slow and eventually decrease because of frame relay, 
SMDS, and other new WAN technologies (see 
“Extended LAN Technologies,” SNA Perspective 
March 1991). 

Many X.25 vendors have switched development of 
products from X.25 to frame relay. X.25 is not an 
efficient backbone technology, with its relatively 
slow data rates of 56-64 Kbps and antiquated 
excessive error checking. Frame relay offers as 
much as a six-to-one cost/performance advantage 
over X.25. The availability of frame relay networks 
will have a profound affect on LAN-to-WAN 
interconnections and on communication controller 
routing now that NCP 6.0 will support frame relay. 
X.25 will still be less expensive than these newer 
protocols for applications, such as terminal-to-host 
applications, that do not require this higher 
performance. This use, and links to international 
sites, will compensate to some extent for the shift in 
routing traffic to newer WAN technology networks. 
Like BSC, X.25 will continue to be heavily used for 
many years. 
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Token Ring 

The communication controller has for some time 
provided a token ring gateway to the host. Each 
subsequent release of NCP has offered more support, 
particularly in the form of additional options and 
flexibility in the area of backup and recovery from 
the failure of a token ring interface coupler (TIC) on 
a communication controller or the associated MAU 
connection. Advantages of token ring over SDLC 
include efficiency/speed, reliability, lower cost, IBM 
commitment, and protocol independence. A token 
ring LAN can transmit not only NetBIOS and SNA 
but other protocols such as OSI. 

One drawback of the.communication controller (and 
many other routers, for that matter) was its inability 
to route NetBIOS from one LAN over the SNA 
backbone to another LAN. This was remedied by a 
kludge solution, called the IBM LAN to LAN Wide 
Area Network Program, that runs under OS/2 EE on 
a PS/2 or PC. NetBIOS can be routed between two 
LANs (token ring or Ethernet) that are both running 
this program. The NetBIOS traffic is encapsulated 
in LU 6.2 and can travel over LAN, SDLC, or X.25. 
Though this program provides an important 
functionality, performance is an issue. 


Need for Low-End Models 

The advantages 6f remote communication con¬ 
trollers for concentration still apply today, although 
the data circuit connectivity requirement is less. 

This creates a market for lower end (and lower cost) 
models. IBM has addressed this need with the 1x0 
model series of the IBM 3745; so has NCR Comten, 
another communication controller vendor. 
Companies such as Brixton Systems have also 
started to get into this market with partial node type 
4 support (see the article “Brixton Systems and 
Node Type 4 Routing Emulation,” SNA Perspective 
August 1991). 

SNA Perspective believes this trend toward a wider 
range of communication controller models will 
continue, with the cost/connectivity differences 
between the lower and upper end models continuing 
to increase. Larger, higher performance models with 
increased connectivity will be used locally as front 


ends to mainframes, with a reduction in the number 
of communication controllers used. Consolidation 
of communication controllers will streamline the 
network and reduce the amount of time and the 
expense of maintaining the network. 

Smaller, lower cost models will be used as remote 
concentrators/SNA routers. These will not be like 
the small models of the past, however. They will 
have increased LAN connectivity and protocol 
support, enhanced WAN connectivity, and sufficient 
performance to process both. 


SNA on Internetworks 

Internetworking of SNA is catching on. The 
important questions for users are: how fast and to 
what extent? 

The advantages of interconnecting SNA and other 
networks include 

• Eliminating link redundancy 

• Lowered equipment costs 

• Transport efficiency 

• Peer networking (new devices do not need to be 
defined in an SNA gen) 

See the “Internetworking and SNA” series, 

SNA Perspective December 1990 and January, 
March, and July 1991. There are a number of 
factors to consider when comparing multiprotocol 
internetworking with SNA routing using commu¬ 
nication controllers; 

• Reliability 

• Support 

• Bandwidth efficiency 

Reliability 

A primary concern is reliability. A communication 
controller (node type 4 or PU 4) is extremely reliable 
at routing SNA traffic because of its ability to use 
virtual routes. When considering the use of a 
multiprotocol internet for SNA traffic, users must 
determine how reliable the equipment and routing 
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method is, compared to using communication 
controllers. If it is less reliable, is it reliable enough 
for the traffic moving over it? The internet protocol 
(IP), for example, discards a packet if it cannot be 
routed. (See the accompanying article in this issue 
for a discussion of how this problem is handled in 
multiprotocol routers with SNA support.) 

Support 

Second, what level of support does the vendor 
provide in the event of hardware and software 
problems? Is the service good enough to support 
mission-critical operations? Can this vendor provide 
for all the user’s internetworking needs now and in 
the future, or will the user need to buy products and 
support from a number of different vendors? 


make the SNA environment more dynamic and 
easier to configure, although these advances appear 
to users to be painfully slow. One major step in this 
direction will be APPN support on VTAM and NCP, 
but this is not expected until early 1993 at the 
earliest and which, in addition, will not address 
existing subarea networks. 

In addition to protocol differences, each different 
internetworking product transports the same data 
using the same protocol with varying WAN effi¬ 
ciency. Premium, sophisticated internet equipment 
will keep WAN expenses to a minimum. 

SNA Perspective cannot overemphasize the impor¬ 
tance of product research and evaluation in selecting 
products for such key elements of a network. 


Efficiency 

Another factor is long-term WAN efficiency. There 
is a significant difference between the amount of 
bandwidth required for connectionless and 
connection-oriented protocols. 

Connectionless Disadvantage—A connectionless 
protocol, such as TCP/IP’s internet protocol (IP), 
requires two or more times the bandwidth of SNA, a 
connection-oriented protocol. Purchasing the extra 
bandwidth required for IP is expensive, more so in 
Europe and the Pacific Rim than in the United States. 
When analyzing the costs of operating a network 
over five years, approximately 85 percent is the cost 
of the bandwidth. In spite of the higher initial 
equipment costs above multiprotocol routers, an 
SNA com-munication controller 


Implementing Internetworking 

Network managers and indeed the entire operational 
staff of an SNA network have a great deal of training 
and experience in NCP, SDLC, and SNA net¬ 
working. Before a move is made to internetwork a 
user’s SNA and non-SNA networks, such staff 
should be trained and gain some experience in 
internetworking. 

SNA Perspective believes the best approach to 
migrating to internetworks is a stepwise progression. 
Users would train the required staff and implement a 
few internetworking connections between LANs 
running noncritical operations to help them gain 


backbone network can be significantly 
less expensive to operate over the life 
of the equipment. 

Connection-Oriented 
Disadvantage—There are also, of 
course, disadvantages to a connection- 
oriented routing protocol. In SNA, in 
particular, one significant challenge is 
having to define the entire network in 
sysgens or NCP gens. One area of 
possible improvement for SNA traffic 
is to inter-network at layer 2 
(bridging) instead of a higher layer 
(routing). IBM has been working to 
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experience. A major challenge will be deciding on 
the method for network management over the inter¬ 
network. It will take years for large users to develop 
experience and confidence in internetworking before 
mission-critical operations are converted. 


The Future of the 
Communication Controiler 

TCP/IP 

IBM has been increasing its focus on TCP/IP, stating 
in June 1991 that it no longer considers TCP/IP to be 
an interim protocol. XSome recent evidence of this 
increased focus is its support of an integral Ethernet 
interface in the 3745 and the ability of NCP to 
transport TCP/IP across an SNA backbone.) This is 
good news for IBM customers. It demonstrates that 
IBM is being more responsive to market demands 
and eases communication between IBM products 
and products from other vendors. 

NCR Comten’s communication processors already 
support both token ring and Ethernet, as well as 
TCP/IP (see the sidebar on the recent NCR Comten 
announcements). Over 20 percent of NCR’s com¬ 
munication processors are shipped with TCP/IP 
support Amdahl, the other IBM-compatible com¬ 
munication controller supplier, has not announced 
plans regarding support of TCP/IP on 
its products (see the sidebar on 
Amdahl communication processors). 


IBM’s implementation of TCP/IP is 
similar to its implementation of X.25 
with XI. The IBM 3745 will be a 
TCP/IP entry point to an SNA net¬ 
work and the TCP/IP traffic will be 
encapsulated in SNA for routing 
across the SNA backbone. Even 
though TCP/IP is a routable protocol, 
IBM will not implement IP natively 
on the communication controller, 
pointing to the inefficiency of routing 
BP as compared to SNA. See Figure 8 
(page 14) on TCP/IP options from a 
mainframe with a TCP/IP protocol 
stack. 


OSI 

OSI was IBM’s original plan for providing routable 
protocol support. However, even its own OSI/CS 
does not support OSI traffic on SNA. Figure 9 
illustrates how IBM’s OSI remote programming 
interface (RPI) can support OSI traffic across an 
SNA network by encapsulating the output from an 
OSI application in LU 6.2 packets, sending them to a 
system with a full OSI stack, which can then send 
OSI packets out to an OSI (not SNA) network, either 
through the 3745 or the 3172. 

WANs 

Now that IBM has decided on frame relay as the 
3745’s high-speed WAN transport combined with 
the higher performance communication control unit 
(CCU) in models 310 and 610, the stage is set for the 
IBM 3745 to support higher speed interfaces. IBM 
has indicated that T3, FDDI, and ISDN will be 
supported on the 3745. See Figure 10 (page 16) for 
an illustration of the variety of options available 
from or announced by IBM for WAN commu¬ 
nications from the 3745. The Architect’s Corner 
column in this issue for a further discussion of the 
3745’s protocol connectivity. 

In addition to frame relay and the higher perform¬ 
ance CCU, IBM has announced its intent to support 
the ESCON channel on the 3745, with a product 
announcement expected in 1992. 
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When it sees s sufficient justification, IBM could 
add other higher speed interfaces such as FDDI and 
T3 to the 3745. SNA Perspective expects FDDI will 
be the successor to token ring for intermediate net¬ 
work node (INN) connections between commu¬ 
nication controllers. 

Because of their bandwidth, SNA Perspective 
believes that IBM considers SONET (Synchronous 
Optical Network) and OC-3 (Optical Carrier-3) as 
better suited to multiprotocol routing, not just one 
protocol such as SNA on the IBM 3745, so we do 
not expect these interfaces to be supported. 

IBM continues to statethat the 3745 has untapped 
potential and will be its communication processor 
platform well into the 1990s. IBM has been concen¬ 
trating on improving the throughput performance of 
the 3745 and reducing the cost of switching packets. 
SNA Perspective believes the company will move to 
enhance NCP performance by introducing more 
parallel processing and off-loading routine tasks to 
the LAN and scanner interfaces. 

APPC 

In its March 1991 announcement of APPN support 
for MVS and VM, IBM committed to supplying 
APPN support for VTAM and NCP by March of 
1993. IBM has also stated that APPN support for 
these operating systems will require only VTAM and 
NCP to be upgraded. CICS, TSO, CMS, application 
interfaces, LU 2, and 3270 will be unaffected. 


SNA Perspective believes that, though this capability 
is unannounced, either NCP version 6.0 will support 
APPN by the time it is released in September 1992 
or perhaps with NCP version 6.1 in early 1993. Last 
month’s SNA Perspective article, “The SNA Subarea 
Under Siege,” addresses the evolution to APPN from 
subarea networking. 


Summary 

If SNA was ever simple, those simpler days of SNA 
networking have passed. Now a plethora of options 
for networking are available. This is good, but not 
necessarily easy. 

Several factors influence the decision to either stay 
with communication controllers as routing nodes, 
integrate them with internetworking routers, or 
replace them at remote sites in favor of LAN and 
internetworking schemes. These are: 

• staff training and expertise 

• hardware life cycles 

• cost (taking all factors into account) 

• corporate strategy 

Looking back at the history of IBM data commu¬ 
nications, development has always been evolu¬ 
tionary. IBM attempted, unsuccessfully, to enact a 
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revolution by not supporting BSC after introducing 
SNA. Future development of SNA will certainly be 
evolutionary too. 

Multiprotocol products, including some from IBM, 
will gradually displace certain traditional SNA 
circuits until an appropriate balance is reached. We 
believe that SDLC will continue to complement 
token ring as a point-to-point solution. 

Communication controller manufacturers will 
respond to market demands by offering new features 
that add value to their products. This same passage 
of time will also give die internetworking equipment 
vendors the opportunity to enhance their products. 

The future of communication controllers in local 
sites as front ends to mainframes looks strong. 
However, as a LAN gateway, it is challenged by 
many products. 

These challengers include non-IBM and IBM 
products, such as the IBM 3172 and future channel- 
attached IBM RS/6000. Communication controllers 
at remote sites, a significant 40 percent of the 
communication controller market, are in the center 
of the internet millistorm. 

There is no doubt that the remote communication 
controllers and internetworks will coexist—with 
users being the beneficiaries of open commu¬ 
nications to IBM and non-IBM host or peer systems 
and increased speed and efficiency. To what degree 
the remote communication controllers coexist will 
depend on how well they are adapted to the 
changing market segment and their total cost 
compared to other internetworking solutions. ■ 


Routing SNA 

SNA is referred to, in the internetworking world, 
as a nonroutable protocol. This is because SNA 
does not provide an open interface except on 
top of layer 2 (for the data link layer) and at the 
presentation layer (SNA’s function management 
layer) for LU sessions. 

The SNA and OSI layers are somewhat, but not 
precisely, comparable. First, the division of 
functions between architectural layers is not the 
same. Second, the extent of functionality in 
each layer is different. For example, SNA was 
designed with the assumption of an unreliable 
underlying physical network and provides an * 
extremely reliable data link layer. In contrast,- 
TCP/IP tolerates a less reliable data link layer, 
and performs more error detection and 
correction at layers 3 and 4. 

Further, traditional SNA was designed as a 
hierarchical system to support very large data 
environments, so SNA routing depends on 
extensive routing tables and link schedulers. 

The Network Control Program (NCP) code 
(which implements the SNA node type 4) in a 
37x5 communication controller takes some 
three million lines of assembler code. In com¬ 
parison, a Cisco router which supports fifteen 
different protocols—including OSI, TCP/IP, 
Novell’s IPX, Apollo Domain, AppleTalk 1 and 2, 
DECnet Phase IV and V, Banyan Vines, 3Com _ 
3+, X.25, DDN X.25, and XNS—contains 
approximately a quarter million lines of C code. 
Lines of C code cannot be compared directly to 
assembler code, an approximate ratio might be 
five lines of assembler to one line of C. But that 
still translates into only 1.25 million lines of as¬ 
sembler code for the entire Cisco protocol suite. 

Certainly, not all of the NCP code would be 
necessary to provide basic routing functions on 
a multiprotocol router, since some of the NCP 
code is used for front-ending a mainframe and 
would not be needed in a multiprotocol router 
that is providing only SNA routing functions. 
However, it would still be extensive. For 
example, the Brixton BRX PU4 emulation code, 
which emulates basic SNA routing, was created 
in about one-third of a million lines of C, or the 
equivalent of over 1.5 million lines of assembler 
code just for SNA routing. ■ 
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Architect’s Comer 


Front End 
Developments: 

IBM’s “Edge City” 

Syndrome 

-- 

by Dr. John R. Pickens 

In an interview on National Public Radio in Septem¬ 
ber, Washington Post staff writer Joel Garreau 
explores a modem phenomenon brought about by a 
combination of technology and necessity. His theory 
is that a revolution in workplace habits has been 
wrought by technology—personal computers, fax 
machines, and transportation technology. The city 
dwellers of the past have moved their workplaces 
closer to home in sprawling suburban centers, which 
he terms “edge cities.” Effectively, the job has been 
moved closer to the workforce. 

I believe a similar phenomenon is beginning to 
unfold in the IBM world of mainframes (urban 
center) and distributed systems, personal computers, 
and the like, but I won’t repeat that here. Rather, I’ll 
focus on recent architectural developments in 
mainframe access (the transportation network into 
the urban center), and its potential impact on 
fostering the networking equivalent of “edge cities.” 

How Many Roads? Thousands 

How many roads lead to the mainframe? If you stop 
and think about it for a while, I think you’ll be 
surprised. 

In the 1960s, 1970s, and early 1980s, virtually al^ 
enterprise computing was focused on the mainframe. 
Access to the computing resource was through dumb 


terminals or software in personal computers that 
emulated dumb terminals. It is no coincidence that, 
in this early period, very few roads led to the main¬ 
frame. There was one WAN link type—RS-232. 

Two WAN link protocols—BSC and then SDLC. 
Beyond the data link, only one transport protocol— 
SNA. And a virtual dominance of 3270 establish¬ 
ment controllers utilizing these primitive data 
highways to carry dumb terminal traffic to the 
mainframe. 

So what has changed? 

First, an observation. I never cease to be amazed by 
the rate of change in LAN/WAN connectivity alter¬ 
natives. Considering IBM alone, it seems that at just 
about the point that the industry begins to under¬ 
stand IBM’s LAN/WAN/terminal attachment options 
for mainframes, IBM unveils yet another attachment 
strategy and set of attachment options. In fact, the 
picture has gotten sufficiently complex and jumbled 
that one of my motivations for this article was to try 
to put it back in order. 

So how many roads would you guess lead to the 
mainframe? Five? Ten? Fifty? Would you believe 
a thousand? 

It is important to note that, as in any public transpor¬ 
tation system, there are highways, feeder roads, and 
back roads to consider in constructing the answer. 

Mainframe Highways 

How many highways lead to the mainframe? I count 
ten. The key is determining what to count (see 
Figure 11, page 19). 

• SNA, OSI, and TCP through the 3745 

• SNA through the 3174 

• SNA, OSI, and TCP through the 3172 

• SNA, OSI, and TCP through the RS/6000 

I justify counting both the protocol and the hardware 
on the basis that each protocol family branches out 
into a separate mesh network of feeder and back- 
road networks. 
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Channel-Attached RS/6000? 

What is new in this picture is the RS/6000. With 
IBM’s September 1991 announcement cornucopia, 
an attachment strategy was announced that would 
allow for channel-attached RS/6000 systems. Why 
would IBM add yet another front end to the picture? 
Internetworking coverage. 

IBM has publicly discussed its plans for a 
multiprotocol router based on the RS/6000. When 
this happens, then direct channel attachment to the 
mainframe makes sense. Even if it doesn’t, a 
general-purpose minicomputer may not make the 
best platform for concentrating dumb ASCII 
terminal and for providing a portal into the world of 
Unix, AIX, and OSF/DCE computing systems. 
Another possibility for the RS/6000 would be to take 
a more active role in OSI-based and SNMP-based 
network management. Further, because of its 
applications processing power, the RS/6000 
becomes an edge city edifice in its own right. 

I’d like to conclude this analysis by looking at the 
next layer of feeder roads which branch out from the 
main highways (see Figure 12). How many feeder 
roads are there, counting once for each protocol 
family? I count 32. 

• From the 3745: 

SDLC (1), X.25 (3), Token-Ring (3), 

Ethernet (3), T1 (3), Frame Relay (3) 


Mainframe “Highways” 



. TCP 

t / 




Figure 11 


• From the 3174: 

Token ring (1) 

• From the 3172: 

Ethernet (3), Token ring (3), FDDI (3) 

• From the RS/6000: 

Ethernet (3), Token ring (3) 

Fanout Exponentially 

How do I get to thousands? Simple. In the next 
layer of fanout, there are an exponentially increasing 
set of alternatives for connection: subarea nodes, 
APPN nodes, bridges, routers, internets... 

Note that some of the paths I’ve counted are not yet 
shipping, e.g., 3745 Frame Relay. There are other 
paths that I have not counted, e.g., personal 
computers with DFT-based coax attachments to 
3174 establishment controllers, integrated 
mainframe token ring and WAN adapters, and X.21 
and ISDN network connections. 

But the sense of the analysis should be clear. Today, 
many paths lead to IBM’s urban center—the 
mainframe. By analogy, the transport network is in 
place for the construction of the next layer in the 
computing architecture—client/server systems, 
personal computers, workstations—the edge city. ■ 
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IBM Announcements 


The September 
Avalanche 

IBM continued its tradition of a large rollout of 
announcements in September. SNA Perspective 
found few highly significant products in the 
September announcements. Rather, IBM used a 
shotgun approach across mainframes, DASD, 
networking, management, client/server, and 
applications development, taking moderate and 
expected steps in all areas. SNA Perspective expects 
more networicing announcements in October. 

A Database Framework 

IBM unveiled the Information Warehouse, a frame¬ 
work (along the lines of its SAA framework), for 
access to data in a distributed environment. 

Remote-unit-of-work (RUOW) distributed database 
management functions will be supported between 
DB/2, SQL/DS, OS/400 database manager, and OS/2 
database manager (as client). This support is based 
on IBM’s Distributed Relational Database 
Architecture (DRDA). 

NCP6.0 

The primary new features announced were support 
for frame relay and Ethernet. Other features include 
session transmission priority and new virtual route 
alert notification. This seems on the surface not to 
warrant a new version but rather only a new release. 
SNA Perspective expects IBM to add features to 
NCP 6.0 before its release in September 1992. 


TCP/IP 

TCP/IP was added to NCP, allowing TCP/IP support 
from Ethernet through the 3745 either across the 
SNA backbone or into a host with TCP/IP. TCP/IP 
for OS/2 and DOS were enhanced. The OS/2 
product now supports X-Server and X.25 access. 
TCP/IP for DOS now supports NFS client and can , 
operate under Windows 3.0. 

NetView 

NetView Version 2 Release 2 includes two new 
transport implementations of the previously 
announced LU 6.2 support: Management Services 
Transport (MS) for conversations of short duration 
and High Performance Transport (HP) for transfer of 
bulk systems management data. This new release 
also includes several automation features. 

NetView Version 2 Release 3 will include an 
enhanced graphic monitor facility, which will 
manage IBM and non-IBM devices from one OS/2 
workstation, and the Resource Object Data Manager, 
which provides object-oriented services. 

Hosts as NetWare Servers 

LAN Resource Extension and Services/MVS 
(LANRES/MVS) and LANRES/VM are mainframe- 
based server products to support NetWare clients. 
This product was previously available for VM as an 
RPQ product. 

SystemView Data Model 

IBM announced the availability of the data model 
for SystemView. However, though it is consistent 
with emerging OSI management standards, it is still 
incompatible with IBM’s AD/Cycle information 
model in the Respository Manager/MVS. IBM 
sources say this is being addressed internally, which 
SNA Perspective views as a political battle which 
has been going on since SystemView’s 
announcement a year ago. ■ 
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